Minutes, IBIS Quality Committee

27 October 2009

11-12 AM EST (8-9 AM PST)

ROLL CALL
  Adam Tambone
* Anders Ekholm, Ericsson
  Barry Katz, SiSoft
  Benny Lazer
  Benjamin P Silva
  Bob Cox, Micron
* Bob Ross, Teraspeed Consulting Group
  Brian Arsenault
  David Banas, Xilinx
* Eckhard Lenski, Nokia Siemens Networks
  Eric Brock
  Guan Tao, Huawei Technologies
  Gregory R Edlund
  Hazem Hegazy
  Huang Chunxing, Huawei Technologies
  John Figueroa
  John Angulo, Mentor Graphics
  Katja Koller, Nokia Siemens Networks
  Kevin Fisher
  Kim Helliwell, LSI Logic
* Lance Wang, IOMethodology
  Lynne Green, Green Streak Programs
* Mike LaBonte, Cisco Systems
  Mike Mayer, SiSoft
* Moshiul Haque, Micron Technology
  Muniswarareddy Vorugu, ARM Ltd
  Pavani Jella, TI
  Peter LaFlamme
  Randy Wolff, Micron Technology
  Radovan Vuletic, Qimonda
  Robert Haller, Enterasys
  Roy Leventhal, Leventhal Design & Communications
  Sherif Hammad, Mentor Graphics
  Todd Westerhoff, SiSoft
  Tom Dagostino, Teraspeed Consulting Group
  Kazuyoshi Shoji, Hitachi
  Sadahiro Nonoyama
  Lijun, Huawei

Everyone in attendance marked by *

NOTE: "AR" = Action Required.

-----------------------MINUTES ---------------------------
Mike LaBonte conducted the meeting.

Call for opens and patent disclosures:

- No one declared a patent.

- Mike noted that a vote of acceptance for the IQ 2.0 spec is planned for
  this Friday at the IBIS Open Forum teleconference.

AR Review:

- Lance try to find IBIS files with [Diff Pin] Tdelay out of order
  - Talked to TI, but have not received a file yet

- All review the IQ spec for possible new IBISCHK checks
  - Discussed in this meeting

New items:

Discussion of possible IBISCHK enhancements based on IQ checks:

Mike: IQ 5.5.3 would be good candidate for IBISCHK
  "5.5.3. {LEVEL 2} [Ramp] dV consistent with I-V table calculations"
- Mike: It would have to use combined I/V tables
  - But IBISCHK does not consider [Add Submodel]
- Bob: [Ramp] must be created with no [Submodel] in effect
- Mike: Why exclude a Driving mode Submodel?
- Bob: [Submodel] is just a parasitic to the base model
- Mike: It should use whatever Submodels are in effect at time 0 in driving mode
  - But if [Submodel] has it's own [Ramp] then maybe the turnon/turnoff
    characteristics are separate
- Lance: So the [Ramp] has to be separated
  - This is not a problem because these models barely exist now
- Anders: We make them separate entities
  - [Ramp] is to create K factors
- Mike: The same would apply to [Driver Schedule] as well
- We agreed that each [Model] [Submodel] and scheduled model has it's
  own [Ramp], so they must be checked uncombined

Lance: Would it be an ERROR or WARNING?
- Mike: Maybe WARNING, since the IBIS spec does not require consistency
- Lance: And [Ramp] may not even be used by simulators
- Bob: It is between CAUTION and WARNING, and will be decided in Open Forum
  - We do not need 2 levels based on percentage for this one
  - This probably should be a CAUTION
- Eckhard: How about a WARNING if waveforms are present, ERROR if not?
- Bob: The dV data are not really used, it should not be an ERROR
  - dV is redundant with waveforms
- Anders: Redundant model data are useful for consistency checks
- Bob: Tools are "on their own" if they use [Ramp] dV for simulation
  - We should have had dt only in the original IBIS specification
- Mike: Did Quad have both dt and dV?
- Anders: They had only dt

Mike: The test model could have no waveforms and 2 point I/V tables
- Anders: If dV is not important why check this?
- Mike: Because dt is derived from the dV thresholds and may also be wrong
- Mike: What should the error threshold be?
- Anders: IQ 5.5.3 says 5% of dV
- Bob: It could be 5% of 100% swing
- Anders: IQ says 5% of the 60% swing
- Mike: We could discuss the percentage at Open Forum this Friday
  - If someone suggests a different number the IQ spec should change

Bob: We will have to consider if we want to generate a new WARNING
- Mike: Not many models will fail this, in our experience
- Anders: Some simulators use [Ramp] for initial timestep determination
  - People don't know how to handle this
- Mike: Then I agree with Bob that it should be a CAUTION
- Bob: It should be sent to the ibis-bug email list

AR: Mike write IBISCHK bug for 5.5.3

Anders: Does the IQ spec suggest using the IBISCHK -caution option?
- Mike: Not inclined to make a last minute IQ spec change for this
  - We would want to look over the existing CAUTIONs first
- Bob: CAUTION gives more information
  - It is usually for something that does not have a serious impact
  - It helps to see if you missed something

Anders: We should keep a wishlist
- Mike: Should the wishlist be in the minutes like the ATM or on our web page?
- Anders: It should be on the web page

AR: Mike add wishlist to IQ web page

Mike: What next?
- Mike: We could begin work on correlation and the Accuracy Handbook next week
- Moshiul: We should discuss updating the IQ checklist spreadsheet
- We agreed to this

Mike will send an Open Forum email when we are about to discuss correlation

Meeting ended at 11:59 PM Eastern Time.
